REMARKS 



The Application has been carefully reviewed in light of the Office Action 
dated March 14, 2003 (Paper No. 12). Claims 1 to 19 and 24 to 38 are in the application, 
of which Claims 1, 11, 24 and 33 to 38 are the independent claims. Claims 1, 7, 9, 1 1, 13, 
14, 16, 18, 24, 29, 31 and 33 to 38 are being amended herein. Reconsideration and further 
examination are respectfully requested. 

With respect to the drawings, Figure 3 A is being amended herein to include 
a prior art legend. With respect to the objection to the drawings as not showing a controller 
as recited in Claim 1, it is submitted that the Figure 2 provides one example of a controller 
having the claimed features, i.e., central processing unit 28. Accordingly, Applicants do 
not believe that any change to the drawings and/or the claims is necessary. 

The claims have been objected to based on alleged informalities. More 
particularly, Claims 1, 11 and 33 to 35 are objected to, and the Office Action suggests that 
each occurrence of the "the bus" wording be amended to read "the internal bus". It is 
believed that the wording of these claims is sufficiently unambiguous and understandable. 
Accordingly, no change is believed to be necessary. In addition and with respect to Claims 
2 to 10, 12 to 19 and 25 to 32, the Office Action indicates that the wording in the preamble 
be changed from "A system" to "The system". The language used in the preamble of these 
claims is believed to be a commonly-used format, and is further believed to be sufficiently 
clear and understandable. Accordingly, no change is believed to be necessary. 

Claims 7 to 9, 1 1 to 18, 29 to 31 and 33 to 35 have been rejected under 35 
U.S.C. § 1 12, second paragraph. Applicants have reviewed the claims in light of the 
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rejection and have amended the claims as deemed appropriate. Reconsideration and 
withdrawal of the rejection are respectfully requested. 

Turning to the art rejections, Claims 1 to 4, 10 to 13, 19, 24 to 26 and 32 to 
38 have been rejected under 35 U.S.C. § 103(a) over Standi in view of the Technische 
University's "Packet: header and data" (Technishe) and TechEncyclopedia' s "TCP/IP 
abc's" (TechEncyclopedia), and Claims 5 to 9, 14 to 18, 20 to 23 and 27 to 31 have been 
rejected under 35 U.S.C. § 103(a) over Standi in view of Technische, TechEncyclopedia 
and Moore's "IEEE 1394: The Cable Connection to Complete The Digital Revolution". 

The present invention relates to a system for transmitting and receiving data 
over a IEEE 1394 standard bus using the same broadcast channel. 

Conventionally, the IEEE 1394 standard bus (1394 bus) provides for 
isochronous transmission of data packets. Any device that uses the IEEE 1394 standard for 
isochronous transmission of data, is assigned an isochronous channel, ranging in value 
from 0 to 63. The channel is assigned to a specific device until it is released by that device. 

However, many different digital video cameras are designed to transmit 
over a single preset channel number, or "broadcast channel" for transmitting digital video 
data packets over the 1394 bus. Because the IEEE 1394 standard does not allow more than 
one device to use the same isochronous channel at one time, only one of the digital video 
cameras is permitted isochronous bandwidth and use of channel 63 to perform transmission 
of isochronous data on the bus. By using multiple 1394 buses, it is possible to allow two 
or more digital video cameras to use the same channel designation, each on a different 
1394 bus. 
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In a February 27, 2003 telephone interview, a summary of which was 
attached to the present Office Action, the Examiner inquired with respect to the use of 
multiple 1394 buses. 1 

In response and as described in the present application, the present invention 
uses multiple 1394 buses to solve the above-discussed problem. However, there is the 
further problem of differentiating between different devices when each device uses the 
same channel designation, even in a case that these devices use different 1394 buses. The 
present invention solves this problem, and interprets an identification (ID) header, which is 
different from the 1394 header, to identify which of multiple interfaces should receive data, 
and also uses the ID header to build the 1394 header. 

Turning to the particular language of the claims, Claim 1 defines a system 
for transmitting and receiving data packets formatted in IEEE 1394 standard between 
devices using a same broadcast channel, comprising a controller interfaced to an internal 
bus, a first interface connected to the bus, and a second interface connected to the bus, 
wherein the controller is configured for 1) receiving data from the bus, attaching an 
identification (ID) header to the received data, and retransmitting the received data with the 
ID header onto the bus; and 2) receiving data with the ID header attached thereto, 
interpreting the ID header to identify which of the first or second interfaces should receive 
the data, and transmitting the data over the bus to the identified interface, wherein the ID 
header is other than a 1394 header formatted in IEEE 1394 standard and contains 

-In this regard and during the February 27, 2003 interview, the Examiner informed 
Applicant's undersigned attorney that he would not take action on the case for at least a 
week. When Applicant's representative contacted the Examiner well within this time 
frame, the Examiner informed her that he had instead elected to issue an Office Action. 
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information about the data, and wherein the 1394 header is built based on information 
contained in the ID header. 

To illustrate by way of example with reference to Figure 2, CPU 28 
interfaces with a first 1394 interface, comprising layers 20 and 21, and CPU 28 interfaces 
with a second 1394 interface, comprising layers 25 and 26, via internal bus 22. CPU 28 is 
configured to receive data from bus 22, attach an ID header to the received data, and 
retransmit the received data with the ID header onto bus 22; and to receive data with the ID 
header attached thereto, interpret the ID header to identify which of the first or second 
interfaces should receive the data, and transmit the data over the bus to the identified 
interface. In addition to being used to identify which of the first and second interfaces 
should receive the data, the ID header, which is other than a 1394 header formatted in IEEE 
1394 standard, contains information about the data and is used to build the 1394 header. 

Standi is not seen to teach or suggest the above-described features of Claim 
1. Most particularly, Standi is not seen to teach or suggest interpreting an ID header to 
determine which of a first and second interface should receive the data, and using the ID 
header, which is other than a 1394 header, to build the 1394 based on information 
contained in the ID header. 

Rather, Standi is seen to describe a hardware configuration in which 
hardware devices can be slipped in and out of device bays easily in a manner similar to the 
laptop computer bays that accept a battery, floppy disk drive, CD-ROM drive, etc. Each 
device bay has a 1394 port and a USB port. In this regard, the problem intended to be 
solved by Standi is the need for a secondary 1394 PHY host controller bus driver and 
associated USB device bay controller, which occurs when a primary 1394 PHY host 
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controller is incorporated on the motherboard and the chassis has multiple device bays. To 
address this problem, Standi describes mounting a plurality of 1394 ports on the riser card, 
which are coupled to a single 1394 PHY host controller and a single bus driver. 

Nothing in Standi is seen to teach or to suggest attaching an ID header to 
data received from an internal bus, or removing an ID header from data received from the 
internal bus, interpreting the ID header to identify the interface that should receive the data, 
and using the ID header, which is other than a 1394 header, to build the 1394 header. 

The remaining references, namely Technische and TechEncyclopedia, are 
not seen to remedy the deficiencies noted with respect to Standi. Technische and 
TechEncyclopedia are merely seen to describe a network packet. These references are not 
seen to disclose interpreting an ID header, which is other than a 1394 header, to determine 
which interface should receive data, and building a 1394 header based on information 
contained in an ID header. 

To illustrate by way of an analogy and as described in TechEncyclopedia, a 
TCP/IP packet identifies an application for delivery based on an IP address, which 
identifies a network node, and a port designation, which identifies an application on the 
network node. A port designation may identify an FTP (File Transfer Protocol) 
application, for example. However, a conflict arises when two instances of the same 
application on the same network node use the same port designation. TechEncyclopedia, 
and Technishe for that matter, is not seen to address this problem. Use of a conventional 
packet, such as a TCP/IP packet containing an IP address and a port designation, is not 
seen to be able to address a conflict that arises when two applications use the same port 
designation. 
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As discussed above, a conflict arises when two devices, albeit on different 
1394 buses, use the same channel designation. A network header, such as that shown in 
Figure 3D of the present application, is not seen to provide information sufficient to 
resolve the conflict. The channel designation in the 1394 data packet shown in Figure 3 A 
is also not seen to provide sufficient information to resolve the conflict, since the same 
channel designation is used by each of the devices. However, the ID header of the present 
invention, an example of which is shown in Figure 3D, is other than a 1394 header, is 
interpreted to identify which interface should receive the data, and is used to build the 1394 
header. 

Nothing in the applied art, namely Standi, TechEncyclopedia and 
Technische, is seen to disclose these features of the present invention. 

Therefore, for at least the foregoing reasons, Claim 1 is believed to be in 
condition for allowance. Further, Applicants submit that Claims 1 1, 24 and 33 to 38 are 
believed to be in condition for allowance for at least the same reasons. 

The remaining claims are each dependent from the independent claims 
discussed above and are therefore believed patentable for the same reasons. Because each 
dependent claim is also deemed to define an additional aspect of the invention, however, 
the individual consideration of each on its own merits is respectfully requested. 

In view of the foregoing, the entire application is believed to be in condition 
for allowance, and such action is respectfully requested at the Examiner's earliest 
convenience. 



-21- 



Applicants' undersigned attorney may be reached in our Costa Mesa, 
California office at (714) 540-8700. All correspondence should continue to be directed to 
our below-listed address. 

Respectfully submitted, 




Registration No. 



FITZPATRICK, CELLA, HARPER & SCINTO 
30 Rockefeller Plaza 
New York, New York 10112-2200 
Facsimile: (212) 218-2200 

CA.MAIN 66555 v 1 
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